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During  FY  1077.  I RSP  Project  94%,  entitled  "Distributed-Processing 
Simulator,"  was  authorized  to  design  and  fabricate  portions  of  a radar 
simulator.  This  document  reports  the  background  and  objectives 
associated  with  the  project,  and  records  the  accomplishments  and 
conclusions  produced  under  this  effort. 

The  Distributed-Processing  Simulator  was  patterned  after  a simulator 
spec i f i cat i on  for  the  ABBA  program,  which  is  responsible  for  Tactical 
Air  Control  System  ;TACS)  improvements.  The  simulator  reguired  by 
this  program  is  intended  for  training  personnel  at  Control  and 
Reporting  Centers  or  Posts,  and  simulates  an  air  surveillance  radar. 

The  Distributed-Processing  Simulator  project  was  an  outgrowth  of 
earlier  work  supported  by  Technology  Base  funding  and  directed  towards 
the  exploitation  of  low-cost  electronics.  Objectives  in  establishing 
the  simulator  proiect  were  to  utilize  low-cost  electronics,  demonstrate 
that  distributed  processing  could  lead  to  lower  cost,  and  gain  some 
experience  with  distributed-processing  architecture. 

The  eguipment  designed  and  fabricated  under  this  project  provided 
the  critical  parts  of  a simulator  which  produces  a standard  Plan 
Position  Indicator  (PPP  display  associated  with  an  air  surveillance 
radar.  The  system  reguirement  is  relatively  complex  and  demanding; 
some  200  "aircraft"  are  kept  under  surveillance  with  the  display 
always  properly  reflecting  the  simulated  scenario.  Modification 
of  the  aircraft  parameters  is  permissible  at  any  time,  initiated  bv 
either  man  or  machine. 

The  simulator  consists  of  a supervisory  network  which  provides  system 
control  and  the  man-machine  interface,  a target  generator  module  which 
generates  target,  (aircraft)  video,  and  a standard  radar-tvne  PPl 
display.  System  references  related  to  pulse  repetition  frequency 
(PRF),  antenna  angle  (bearing),  and  scenario  time  are  also  provided. 

The  project  made  extensive  use  of  low-cost  Large  Scale  Integrated 
electronics,  including  RAM's  (random  access  memory),  ROM's  (read-only 
memories),  the  most  recently  available  logic  types  of  integrated 
circuits,  and  a relatively  new  microprocessor,  the  TMS-9900. 


Interest  in  exploring  wavs  to  reduce  development  cost  was  based  on 
two  lines  of  argument:  (1)  that  development  time  or  manpower  is  more 
influential  on  cost  than  hardware,  and  (2)  that  distributed  processing 


offers  an  opportunity  to  partition  a project  and  permit  parallel 
but  more  importantly  independent  desiqn  activities.  Proper 
partitioning  allows  the  designers  to  assign  plenty  of  "hardware  and 
software  space"  to  critical  areas  of  the  system,  and  thereby  avoids 
the  time-consuming  and  error-provoking  optimization  usually  encountered 
in  constrained  centralized  archi tectures . As  a result,  our  design 
activity  proceeded  in  a straightforward  manner,  with  no  complications 
requiring  extra  development  time  or  difficult  solutions.  Because  the 
design  and  implementation  of  the  modules  and  system  software  did  in- 
deed proceed  smoothly  and  in  parallel,  and  because  system  integration 
and  test  was  almost  trivial,  we  conclude  that  the  potential  cost 
benefits  of  distributed  processing  can  be  substantial.  Our  experience 
re-emphasized  the  importance  of  fully  exploring  the  system  architecture 
before  module  and  software  design  begins. 

In  operational  terms,  the  project  resulted  in  a small  system  which 
did  everything  that  was  expected  of  it,  and  the  quality  of  the  radar 
responses  presented  on  the  PPI  display  was  judged  "very  satisfactory" 
by  experienced  observers. 

The  report,  concludes  with  reference  to  some  of  the  possible  avenues 
along  which  this  initial  effort  could  be  extended;  they  include  other 
forms  of  radars,  and  explorations  of  LCM/ICCM  relationships  in  both 
radar  and  communication  systems. 
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This  photo  shows  the  equipment  designed  and  built  under  the  9490 
Project.  At  the  left  is  the  PFI  display  (AN/UPA-35  loaned  to  the 
project);  at  the  center  is  the  rack  containing  the  Target  Generator 
and  the  Supervisory  Minicomputer;  and  located  on  the  table  is  the  CRT/ 
keyboard  Terminal  which  provided  the  man-machine  interface  to  the 
system. 

The  photo  incidentally  shows  some  members  of  the  design  team:  from 
left  to  right.  Ivan  La-Garde,  Paul  Buote,  and  Victor  kross. 
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ACRONYMS/ABBREVIATIONS 


USED  IN 

THIS  REPORT 

A/C 

Ai rcraft 

AZ 

Azimuth 

CPU 

Central  Processor  Unit 

CRT 

Cathode  Ray  Tube 

EPROM 

Electronically  Programmable  ROM 

I/O 

Input/Output 

ppr 

Plan  Position  Indicator 

PPS 

Pulses  per  Second 

PRF 

Pulse  Repetition  Frequency 

RAM 

Random  Access  Memory 

RCS 

Radar  Cross-Section 

ROM 

Read-Only-Memory 

sir 

Selective  Identification  Feature 

SRN 

Scenario  Reference  Number  (Refers  to  a target) 

STEM 

System  Trainer  and  Exercise  Module 

TGM 

Target  Generator  Module 

TTY 

Teletype 
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SECTION  ! 


INTRODUCTION 


Background 

In  order  to  introduce  the  Distributed-Processing  Simulator  project 
funded  under  I RAP  account  T490,  one  must  first  understand  some  of 
the  background  which  led  uo  to  the  9400  project. 

This  background  started  in  EY76-EY7T  under  an  Air  Force  Technology 
Base  effort  (Project  70101,  responsible  for  the  exploitation  of  Low- 
Cost  llectronics.  Under  the  7010  effort  we  sought  a system  problem 
which  would  be  a suitable  vehicle  for  extending  our  work  in  low- 
cost  electronics,  and  at  the  same  time  offer  an  opportunity  to  learn 
more  about  the  application  of  distributed  processing  as  a design 
technique. 

The  candidate  system  selected  under  the  7010  effort  was  a small 
system  simulating  the  AN/TPS-43  air  surveillance  radar,  with  its 
associated  display  and  interfaces  to  other  surveillance  centers. 

A requirement  for  such  a simulator  had  already  been  established  for 
the  485 A program  and  the  simulator  was  identified  as  STEM  (System 
Trainer  and  Exercise  Module).  Of  further  interest,  a recently 
generated  speci fication  on  STEM  was  available  and  it  represented  a 
real,  rather  than  synthetic,  challenge  for  our  investigation.  The 
design  effort  aimed  to  meet,  in  principle  if  not  in  detail,  the 
munv  and  exacting  requirements  specified  for  the  system. 
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The  diaqram  qiven  in  fiqure  1-1  shows  the  STEM  system  and  its 
interconnections  as  defined  by  the  specification.  The  major 
components  of  the  system  are: 


an  AN/TPS-43  radar,  or  its  equivalent,  which  provides 
qenuine  radar  video. 


a computer-controlled  simulator  which  provides  synthesized 
radar  video. 


a mixer/switch  unit  which  provides  for  transfer  of  either 
or  both,  qenuine  or  synthetic  radar  video,  and 


4)  a standard  Plan  Position  Indicator  (PP1)  display 
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STEM  System  and  its  Interconnections 


STEM  System  Trainer  and  Exercise  Module' 
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CROSS-TELL 
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Figure  1-2  shows  the  distributed-processing  version  of  a computer- 
controlled  radar  simulator  patterned  after  the  STEM  requirement. 
This  concept  was  established  under  the  Pro.iect  7010  effort  and  the 
principal  components  are: 

1)  a bank  of  video  generation  modules  to  generate  the  radar 
video, 

2)  a supervisory  minicomputer  to  control  the  operation  of 
the  video  generation  modules, 

3)  a bank  of  pilot  simulators  for  simulating  certain  aircraft 
and  their  human  control  interface,  and 

4)  a director's  console  which  permits  control  and  observation 
of  the  system  operation. 
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STEM  System  Trainer  and  Exercise  Module 


Project  7010  Hardware  IVsign 


With  a system  problem  selected  and  a proposed  system  design  agreed 
upon,  project  7010  then  started  some  hardware  development..  lor  the 
initial  detailed  engineering  design  effort  the  Target  Oenerator 
Module  was  selected,  partly  because  it  appeared  to  be  the  most 
challenging,  and  partly  because  its  outputs  a re  reguired  bv  other 
modules  within  the  system. 

By  April  i^/7,  project  7010  efforts  on  the  radar  simulator  produced 
a conceptual  system  block  diagram  (figure  1-4),  a block  diagram  for 
the  target  generator  module,  and  some  pieces  of  hardware  which  met 
the  regul foments  of  part  of  the  target  generator  module.  Ihis  hardwart 
formed  an  assembly  identified  as  the  Antenna  Scan  Modulator,  and 
coupled  with  it  were  a single  video  generator  channel  and  deflection 
circuits  designed  to  drive  a PP1  display  (Plan-I’osi tion  lndicatorl. 

The  system  block  diagram  a paper  design  and  these  tew  pieces  of 
hardware  formed  the  platform  from  which  project  ‘>4 op  was  lautuhed 
in  May  H77. 
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-u  v 

v c 


Figure  1-3.  Simulator  Hardware  Produced  under  Project 


mu i *»«' 


I he  ‘MOO  Proiei  t 


figure  1-4  shows  t ho  system  block  diagram  of  the  distributed- 
processing  version  of  the  STl  M simulator  conceived  under  the  project 
7010  effort. 

1 tie  top  layer  of  blinks  provides  the  supervisory  network  which 
consists  of  tln>  supervisory  minicomputer  and  its  associated  periph- 
erals. Within  this  group,  the  block  labeled  "Supervisors  Display" 
represents  the  Director's  Console  shown  in  figure  1-2. 

1 he  various  video  generation  modules  are  shown  feeding  the  Video 
Combiner,  uiul  the  Selective  Identification  Function  (SIT)  Module  feeds 
directly  to  the  DPI  since  that  signal  is  processed  through  a separate 
rece i ver . 
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Miiuro  1 4.  System  Block  Diagram,  Distributed-Processing 
Version  of  STFM 
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There  was  not  sufficient  fuiulim]  available  to  support  a full  develop 
went  program  and  therefore  pro, lei  t '>400  efforts  were  directed  towards 
a limited  version  of  the  system,  figure  1 S shows  the  project  4490 
version  of  the  distrihuted  processing  simulator.  Only  the  critically 
important  elements  received  detailed  attention;  these  were: 

• system  engineering,  represented  hv  the  supervisory  network 
and  tiie  comminicat  ion  arrangements 

• system  references,  which  are  necessary  for  the  system 
to  operate 

• the  Target  Generator  modulo,  and 

• the  I'Pl  display. 

The  eguipment  which  was  produced  under  this  project  met  the  task 
objectives  of  providing  Ml  IK!  with  experience  in  distributed 
processing  design,  demonstrating  some  characteristics  critical  to  a 
realistic  radar  simulation,  and  providing  a system  which  would 
gracefully  accept  system  growth. 
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Figure  1-5.  Project  9490  Version  of  distributed -Processing  S11M 
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SECTION  II 
THE  9490  SIMULATOR 

The  UUO  Project  9490  was  established  with  several  objectives: 

1)  to  provide  son*'  experience  in  designing  a system  utilizing 
distributed  processing  techniques.  We  were  interested  in: 

- architecture  and  its  impact  on  module  design, 

- possible  problems  in  module-level  and  system-level  testing, 

- possible  problems  in  system  integration, 

- the  inefficient  use  of  hardware  and  its  impact  on  the 
module  design,  and 

2)  to  demonstrate  our  initial  belief  that  distributed  processing, 
as  a design  technique,  offers  an  opportunity  to  reduce  system 
cost,  reduce  development  tin*',  and  provide  system  flexibility. 

3)  to  build  an  equipment  which  could  he  used  as  a base  for 
further  work  in  either  distributed  processing  or  simulators. 

The  Project  9490  Simulator  was  patterned  after  the  complete  system 
defined  under  the  earlier  phase  funded  by  Project  7010,  Low-Cost 
Electronics,  and  the  system  block  diagram  is  shown  in  figure  2-1. 

The  equipment  consists  of: 

• a supervisory  network  which  provides  in  equivalent  form 
all  the  functions  called  for  in  the  complete  design. 

• a set  of  system  references  which  define  antenna  angle 
rate,  radar  PRF,  and  scenario  time. 

• the  Target  Generator  module  which  satisfies  all  of  the 
requirements  set  by  the  full-svstem  design. 

• a video  combiner  and  noise  source  which  are  a minimum 
equivalent  of  this  function  in  the  full -system  design. 

• a PPI  display  — the  AN/UPA-35. 

An  important  part  of  the  simulator  design  also  concerned  the  bus 
structure  and  message  structure  between  the  Supervisory  Minicomputer 
and  the  video  generation  modules. 

Supervisory  Network 

Five  major  functions  are  provided  within  the  Supervisory  Network 
and  they  are  described  in  the  following  paragraphs. 
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Figure  2-1.  Project  9490  Version  of  the  Radar  Simulator 


The  Supervisory  Minicomputer,  as  its  name  implies,  is  primarily 
responsible  for  supervision  and  control  of  the  simulator  operations, 
as  distinct  from  doing  the  many  real-time  computations  which  are 
done  in  the  video  generation  modules.  Some  computation  is  done 
within  the  Supervisory  Minicomputer,  and  this  is  the  conversion  of 
inputs  expressed  in  Standard  Air  Force  units  (range,  azimuth, 
heading,  velocity,  height)  to  units  suited  to  the  design  of  the 
Target  (ienerator  and  other  video  generation  modules  (position  in  x, 
y,  z;  velocity  in  x,  y,  z;  and  acceleration  in  x,  v,  z). 

The  CRT /Keyboard  Terminal  provides  the  functions  required  ot  the 
Simulation  Director's  Console;  these  are  basically  intended  to 
permit  manually  initiated  aircraft  flights,  modify  any  of  the  air- 
craft flight  patterns  within  the  simulator,  or  permit  the  input  of 
stored  data  to  control  aircraft  flight  patterns.  The  CRT/Keyboard 
Terminal  is  also  able  to  interrogate  either  the  Supervisory  Mini- 
computer or  the  video  generation  modules  to  determine  the  status, 
at  any  time,  of  the  scenario  being  simulated. 

The  Paper  Tape  Reader  satisfies  the  functional  requirement  to  permit 
preprogrammed  scenarios  to  be  utilized  in  the  system.  One  may 
utilize  the  preprogrammed  capability  to  simply  establish  an  initial 
scenario,  or  one  may  have  a complete  scenario  development  stored  on 
paper  tape  and  have  it  played  out  through  the  simulator. 

17 


CK  T ('.itluulc  M.ty  ) ulv 


A more  fully  developed  version  of  this  simulator  would  employ  magnetic 
records  to  establish  scenarios,  and  since  the  quantity  of  data  is 
quite  limited  only  changes  in  status  are  noted,  and  these  are 
expressed  In  symbolic  terms  a standard  digital  cassette  would  be 
adequate  for  most  applications. 

The  Paper  Tape  Punch  is  provided  to  permit  creation  of  new  scenarios 
from  existing  ones.  This  is  done  by  feeding  an  existing  scenario  to 
the  system  and  manually  inputting  changes  from  the  CRT/ keyboard 
Terminal.  Resulting  control  messages  issued  by  the  minicomputer  are 
fed  to  the  paper  tape  punch  as  well  as  the  video  modules  and  a new 
scenario  record  is  thus  created. 

The  Teletype  (TTY)  is  provided  so  that  a hard  copy  may  be  made 
available  from  the  data  presented  to  the  CRT  terminal.  In  normal 
use  it  is  beneficial,  after  a simulation  exercise,  to  permit  an 
evaluation  of  some  of  the  actions  taken  during  the  exercise,  and  a 
hard  copy  of  the  relevant  data  permits  this  guite  readily.  In  a 
more  fully  developed  system  the  hard  copy  would  be  better  provided 
by  equipment  specifically  designed  for  the  purpose;  most  significantly 
it  would  have  a faster  writing  rate,  and  probably  be  capable  of  also 
recordina  graphics  as  well  as  aloha-numerics. 

System  References 

The  system  references  required  to  penult  operation  of  the  simulator 
relate  to: 

- antenna  position  or  rotation  rate 

- radar  PRT,  and 

- scenario  time. 

Outputs  from  these  sources  are  fed  to  t lie  modules  and  supervisory 
minicomputer  so  that  synchronism  is  maintained  among  the  various, 
and  otherwise  independent,  functions  w i thin  the  simulator. 

Currently  used  standards  define  antenna  position  by  a 12-bit  digital 
word  which  is  equivalent  to  one  bit  per  0.088  degrees.  Thus  an  antenna 
rate  of  6 revs/min.  (typical  for  a search  radar)  would  be  expressed 
as  a pulse  rate  of  410  pulses/second.  Conversion  from  antenna  rate 
to  antenna  position  involves  a simple  counting  arrangement  and  the 
generation  of  a north  strobe. 

As  we  see  in  figure  2-2,  the  antenna  rate  is  defined  by  a standard 
pulse  generator  instrument.  This  was  used  so  that  we  could  emphasize 
the  flexible  nature  of  the  simulator;  although  it  was  intended 
primarily  to  simulate  a search  radar  with  an  antenna  rate  of  (say) 

6 revs/min.,  it  is  able  to  operate  at  any  rate  from  stationary  to 
perhaps  several  revs/sec.  the  limit  relates  to  target  density,  not 
to  antenna  rate. 
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Figure  2-2.  System  Reference  Hardware 

The  Radar  prjf  is  provided  by  another  pulse  generator  whose  output 
is  utilized  to  simulate  the  trigger  normally  available  from  a radar 
transmitter.  As  with  the  antenna  rate,  the  simulator  is  flexible 
in  terms  of  permitted  PRF  values;  however;  since  it  takes  a finite 
time  to  process  each  of  the  required  200  targets,  there  is  an  upper 
limit  to  the  PRF  of  approximately  330  pulses/sec. 

The  System  Clock  provides  time  information  used  by  the  various 
modules  in  the  system.  Since  many  operations  are  predicated  on  an 
interrupt  mechanism,  one-second  pulses  are  made  available  to  the 
system.  Scenario  time  is  also  required  for  some  operations  and  this 
is  provided  as  a 16-bit  number  updated  once  per  second;  scenario  time 
is  also  displayed  on  the  front  panel. 

The  system  clock  also  has  a "Faster  Than  Real-Time"  mode  of  operation 
which  is  useful  for  speeding  to  some  point  in  a scenario  development, 
or  for  observing  the  development  of  a scenario  at  faster  than  normal 
rate. 

The  Target  Generator  Module 

Inputs  to  the  Target  Generator  Module  consist  of  instructions  provided 
by  the  Supervisory  Minicomputer,  and  the  various  references  supplied 
by  the  System  Reference  Group.  Provided  with  these  inputs  the 
Target  Generator  Module  generates  video  pulses  as  required  for  a PPI 
display.  These  pulses  are  generated  in  proper  synchronism  with 
the  "rotating  antenna"  and  are  appropriately  responsive  to  aircraft 
characteristics  such  as  position,  aspect  angle,  radar  cross-section, 
and  range. 
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Figure  2-3.  Target  Generator  Module  Interfaces 

The  output  of  the  Target  Generator  Module,  as  shown  in  figure  2-3, 
is  video  which  is  fed  to  the  PPI  z-axis.  The  Target  Generator  Module, 
as  it  was  built  under  the  9490  project,  also  provided  blanking  and 
deflection  signals  for  the  PPI  display;  this  was  done  as  a practical 
convenience  although  these  signals  would  not  normally  be  regarded 
as  part  of  the  target  generation  function. 

V ide o Comb in  er 

The  Video  Combiner  incorporated  into  this  version  of  the  radar 
simulator  is  very  limited  in  objective;  it  has  a transfer  characteris- 
tic which  soft-limits  on  signals  greater  than  about  2.5  volts,  and 
it  combines  the  gain-compressed  output  with  noise  provided  by  a 
standard  noise  generator. 


Plan  Positj on  Indicator  (PPI ) 

The  radar  simulator  makes  use  of  two  PPI  displays;  one  is  small  and 
conveniently  mounted  in  the  equipment  rack  — this  is  a Hewlett- 
Packard  1300A  xy  display  adapted  for  the  task  — the  other  is  a 
standard  military  equipment,  the  AN/UPA-35.  The  smaller  unit  is 
useful  for  quick  or  simple  system  checks;  the  larger  unit  provides 
an  excellent  means  of  observing  the  simulated  radar  responses  and 
provides  a more  accurate  measure  of  the  fine-grain  performance  of 
the  simulator. 
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Operations  and  Confutations 


The  operations  and  computations  implemented  at  system  level  are 
summarized  in  table  2-1. 


OH  RATIONS 


• Initialize  the  system 

• Establish  an  initial  scenario 

• Modify  scenario  in  proqress 

• Establish/modify,  radar  power  and  height 

(16  aircraft  types,  5 values  of  radar  cross- 
section) 

• Control/Interrogate  modules 


COMPUTATIONS 


• Convert  range,  azimuth,  heading,  velocity 
and  height  to  x,y,z,x,y,z. 


OFF-LINE  • Converts  latitude/longitude  to  x,y,z,x,y,z. 

SCENARIO 

GENE  RATION 


Table  2-1.  System  Level  Operations  and  Computations 


The  primary  responsibility  of  the  minicomputer  is  to  accept  data  from 
one  source  (e.g.,  the  scenario- tape  reader)  and  send  it  to  another 
(e.g.,  the  target  data  module).  Operations  within  the  supervisory 
minicomputer  are  not  done  in  real  time  but  are  done  during  the  time 
2 to  20  seconds  prior  to  the  real-time  requirement.  In  addition  to 
transferring  scenario  and  operator  commands  and  exercising  control, 
the  minicomputer  does  a little  computation,  principally  related  to 
the  conversion  of  coordinates  from  one  system  to  another.  CPU 
utilization  is  running  at  only  about  2.;  the  minicomputer 
generally  has  nothing  to  do, since  it  only  responds  to  a scenario  "event" 
or  an  operator  display  request.  About  89’.  of  the  available  memory  is 
employed  and  the  memory  utilization  is  given  below. 


TORTRAN  (14  routines) 

34.9 

FORTRAN  functions 

21.7 

(sin,  cos,  etc.) 

Links  S interrupt  vectors 

12.5 

FORTRAN  I/O  drivers 

12.4 

Spare 

11.1 

Tables 

4.9 

Assembly  language 

2.5 

CPU  Conti  Jl  Pnn't’ssni  Unit 
I 0 Input  Output 
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The  freedom  from  real-time  computing  constraints  makes  the  programming 
of  the  minicomputer  a virtually  trivial  exercise.  All  calculations 
and  data  transfers  can  be  written  in  non-real-time  FORTRAN,  and  no 
real-time  operating  system  of  any  kind  is  required.  Furthermore,  the 
system  architecture  and  the  module  designs  have  focused  on  minimizing 
the  amount  of  data  to  he  transferred,  both  within  the  minicomputer 
and  on  the  system  data  bus. 


Communication  between  the  Supervisory  Minicomputer  and  the  various 
video  generation  modules  is  done  on  a bus  structure  designed  in  a 
master-slave  form;  messages  are  fed  in  either  direction,  but  the 
supervisory  minicomputer;  acting  as  master,  always  initiates  and 
controls  any  message  exchange.  The  principal  message  traffic  on  the 
bus  consists  of  conmands,  and  initial  conditions  sent  from  the  master 
to  the  slaves;  communication  does  occur  in  the  other  direction 
although  it  is  done  primarily  to  satisfy  an  interrogation  function 
rather  than  to  continual 1\  feed  data  back  to  the  supervisory  network. 
The  master-slave  bus  arrangement  is  sometimes  regarded  as  a somewhat 
limited  link;  however,  the  very  simple  communication  requirements  of 
the  simulator  are  well-matched  to  the  characteristics  of  the  master- 
slave  concept,  and  the  simulator  is  consequently  provided  with  a 
simple  and  reliable  bus  structure. 


MASTER  - SL  AVE 


SLAVE 


• Basic  pattern,  4 words/message 

• Messages  define 

- position 

- ve  1 oc  i ty 

- acceleration 

- target  masking 

- highlighting 

- radar  altitude 

MASTER 

t These  messages  are  sent  only  in  response  to  status 
requests  from  the  master 


- radar  cross-section 

(16  types,  5 values/type) 

- aircraft  type 
(1  Of  161  " 

- transmitter  power 

- status  requests 


x.y ,z,x ,y  ,z 


Table  2-2.  Master-Slave  Messages 
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STEM  System  Trainer  and  Exercise  Module 


THE  TARGET  GENERATOR  MODULE 


Figure  3-1.  This  photograph  shows  the  Target  Generator  Module. 

It  consists  of  3 assemblies:  the  Target  Processor  Assembly  seen  at 
the  front  of  the  module,  the  Antenna  Scan  Modulator  located  behind 
it,  and  below  (not  visible  in  this  photo)  the  Video  Generator 
Assembly. 


General  Description 


The  Target  Generator  Module  block  diagram  is  given  in  figure  3-2. 

It  is  detailed  to  the  level  that  identifies  all  the  major  functions 
provided  in  this  module. 

Starting  at  the  left  of  the  diagram,  the  first  functional  block  is 
the  I/O  interface  which  provides  the  interface  between  the  Target 
Generator  Module  and  the  Supervisory  Minicomputer.  All  instructions 
given  the  Target  Generator  are  fed  in  via  this  port  from  the 
Supervisory  Minicomputer;  responses  to  interrogations  are  also  fed 
out  of  this  port. 

The  next  significant  block  is  the  Target  Generator's  microprocessor 
which  is  a Texas  Instrument  TMS-9900.  This  is  a 16-bit  processor 
operating  at  a clock-rate  of  approximately  2.5  MHz. 

The  peripherals  supporting  the  microprocessor  are  several  random 
access  memories  (RAMs),  a Read-only  memory  and  some  fixed  logic. 

RAM]  provides  temporary  storage  for  instructions  which  may  be  fed  to 
the  Target  Generator  prior  to  the  effective  time  for  execution, 

RAM2  provides  storage  of  all  target  data  including  current  position, 
and^RAM3  provides  storage  of  target  position  expressed  in  radar 
coordinates  (p,  0).  The  target  table  RAM  provides  storage  for 
data  defining  average  radar  cross  section;  16  aircraft  types,  each 
with  5 different  aspect  angles,  may  be  characterized  by  this  memory. 

I his  memory  is  of  RAM  form  rather  than  ROM  so  that  one  may  change 
the  available  patterns  of  radar  cross  section  during  the  scenario  if 
one  wishes.  The  program  ROM  is  provided  solely  as  a development 
aid  and  is  used  in  conjunction  with  a "front-panel"  set  of  controls 
recessed  behind  the  Target  Generator  Module  front  panel.  The  fixed 
logic  is  a set  of  hardware  designed  to  convert  data  from  linear  to 
logarithmic  form,  or  the  reverse;  this  was  provided  because  an 
initial  estimate  of  the  microprocessor  loading  concluded  that 
valuable  computation  time  could  be  saved  by  utilizing  a hardware 
implementation. 

The  microprocessor  is  fed  time  data  and  antenna  angle  information 
to  permit  properly  synchronized  operation,  rime  expressed  as  a 
l-second  interrupt  is  used  to  initiate  updating  of  target  positions 
in  the  xy  domain,  and  time  expressed  as  a 16-bit  binary  number  is 
used  as  a clock  to  letermine  when  to  implement  actions  specified 
for  a specific  point  ir  time  in  the  scenario.  Antenna  angle  is 
used  to  define  antenna  sectors  of  22h  degrees,  and  conversion  of 
target  position  data  from  xy  form  to  p6  form  is  done  in  blocks 
(or  sectors)  on  an  "as  needed"  basis. 
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Figure  3-2.  Target  Generator  functional  flock  Piagram 


The  data  stored  in  RAM3  (target  coordinates  in  (>o  form)  is  fed  to  the 
succeeding  circuits  on  a sector-by-sector  basis.  The  0 data  is  fed 
through  the  hardware  logic  to  control  the  timing  of  a video  pulse 
generated  to  simulate  the  target. Other  characteristics  stored  in  RAM? 
(0,  target  bearing;  t>,  target  elevation;  and  J),,.a  sensitivity  factor) 
are  combined  with  the  instantaneous  antenna  angle  and  an  antenna 
pattern  ROM  to  define  the  proper  signal  amplitude  to  be  generated  by 
the  simulator.  A pulse-to-pulse  scintillation  factor  is  also  incorp- 
orated into  this  function. 

The  output  of  the  fixed  logic  is  a series  of  digital  words  which 
define  the  relative  time  (range)  and  amplitude  of  the  video  pulses  to 
be  generated  in  response  to  a particular  radar  trigger  pulse.  The 
equipment  built  under  project  l)490  employs  one  assembly  of  4 video 
generators  and  thus,  up  to  4 responses  per  transmitter  pulse  are 
possible.  Expansion  of  the  video  generation  capability  would  be  in 
sub-modules  with  4 video  generator  channels  in  each  sub-module. 

The  video  generator  assemblies  are  of  common  design  utilizing  straight- 
forward hardware  techniques,  and  their  output  is  summed  before  being 
fed  out  as  a video  signal  for  use  in  the  Pi'l  display. 
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The  Target  Generator  Module  also  incorporates  some  circuits  which 
are  not  properly  part  of  the  target  generator  function;  they  were 
located  there  for  practical  convenience.  One  circuit  converts  a 
pulse  train  defining  antenna  rate  to  a statement  of  antenna  angle; 
the  other  circuits  provide  the  x and  y deflection  signals  for  use 
in  the  PPI  display. 

Operations  and  Computations 

The  operations  and  computations  implemented  in  the  Target  Generator 
Module  are  summarized  in  table  3-1,  given  below. 

The  operations  are  basically  concerned  with  accepting  inputs  from 
the  Supervisory  Minicomputer;  these  define  target  positions,  velocities, 
and  parameters  of  the  radar  equation;  from  these  inputs  an 
appropriate  set  of  video  responses  is  determined  and  generated. 

The  computations  relate  to  two  major  requirements:  one,  of  maintaining 
a current  statement  of  position  on  all  targets,  expressed  in  the  xy 
domain;  and  the  other,  of  providing  radar  coordinates  for  all  required 
responses  to  a synthetic  aircraft.  While  the  updating  in  the  xy 
domain  is  done  once  per  second  for  all  aircraft,  the  coordinate  con- 
version is  only  done  for  aircraft  about  to  be  displayed  on  the  PPI.  A 
more  detailed  breakdown  of  the  Target  Generator  computations  is  given 
in  table  3-2 


OPERATIONS 


COMPUTATIONS 


Table  3-1.  Operations  and  Computations  in  the 
Target  Generator  Module 


A/C  ■ Aircraft  27 

Ptx  - Power,  transmit 
RCS  Radar  Cross-Section 


• Accepts  Inputs  on  A/C  at  Any  Time,  Including 

Inputs  Ahead  of  Time. 

• Accepts  Inputs  Defining  P.  , RCS,  Radar  Elev. 

(Initially  and  at  Any  Othe?  Time). 

• Controls  Flow  of  Data  to  Video  Generators. 

• Responds  to  Interrogations  on  Status. 

• Updates  Target  Vector  for  200  A/C  Each  Second 

(Done  in  xyz  domain). 

• Coordinate  Conversion  on  Active  Targets  (A/C). 
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Microprocessor  Timing 

The  timing  associated  with  several  critical  operations  done  within 
the  microprocessor  network  has  been  measured  and  the  results  are 
given  in  table  3-3. 


xy  coordinate  update  = 32  ms/200  targets 

= 160  //s/target 

review  200  targets  each  = 10.5  ms/review 
sector 

coordinate  conversion  = 1.3  ms/target 


Table  3-3.  Timing  of  Microprocessor 
Functi ons 


The  xy  coordinate  update  is  important  because  it  is  done  for  every 
target,  every  second.  The  reviewing  of  all  the  200  possible  targets 
is  required  each  time  the  "antenna"  enters  a new  sector  (22.5  degrees 
wide)  in  order  to  establish  which  targets  should  have  their  current 
xy  coordinates  converted  to  radar  coordinates.  The  time  required 
for  coordinate  conversion  is  important  because  it  is  relatively  long. 

These  operation  times  illustrate  one  of  the  design  features  intended 
for  the  simulator  project,  namely  that  if  the  system  designer  is  given 
plenty  of  design  space  — hardware  or  software  — then  the  design 
activity  will  proceed  expeditiously  and  at  low  cost.  It  was  intended 
that  the  microprocessor  network  be  overdesigned,  and  these  measured 
operation  times  indicate  that,  for  an  antenna  rotation  rate  of  6 rpm 
and  a field  of  200  targets  in  the  radar  purview,  the  microprocessor 
spends  only  about  8T.  of  its  time  making  computations  and  exercising 
control.  Sufficient  margin  was  in  fact  provided  that,  with  certain 
minor  limitations,  the  system  may  be  operated  at  rates  as  much  as  8 
times  faster  than  real  time.  Once  the  initial  design  of  the  target 
generator  had  been  established,  the  implementation  proceeded  without 
any  changes  being  required  and  no  difficulties  in  execution  were 
encountered. 
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Design  Features  of  Interest 

Among  the  features  of  interest  in  the  design  of  thp  Target  Generator 
Module  are  the  scintillation-radar-cross-section  simulation  and 
the  mapping  of  antenna  patterns  in  the  antenna  ROM. 

TYPICAL  HORIZONTAL 


The  radar  treated  as  the  standard  to  simulate  is  the  AN/TPS-43, 
which  is  a 3-D  radar.  This  radar  utilizes  several  vertical  beams 
and  interpolation  between  them  to  determine  the  angle  of  elevation 
of  the  target  of  interest.  Fach  of  the  vertical  beams  has  an 
associated  horizontal  pattern,  and  these  horizontal  patterns  are  not 
necessarily  all  the  same. 

To  accommodate  this  variability  a 3-dimensional  antenna  ROM  is 
employed  in  the  Target  Generator;  this  memory  can,  of  course,  be 
programmed  to  store  any  pattern  set  we  wish  to  define  within  an 
azimuth  gate  of  11.2  degrees  and  an  elevation  space  of  zero  to 
45  degrees.  In  addition  to  defining  antenna  patterns,  the  antenna 
ROM  reserves  one  layer  to  service  a "highlight"  function  used  to 
identify  specified  targets  in  the  PPI  display. 


ROM  Read  Only  Memory 
3D  Three-dimensional 
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PPI  Plan  Position  Indicatoi 
AZ  Azimuth 


When  an  aircraft  is  continuously  "painted"  by  a radar,  the  signals 
received  by  the  radar  are  highly  variable,  this  variability  being 
referred  to  as  scintillation.  Beyond  the  scintillation  effect  one 
can  also  see  a difference  in  the  average  value  of  the  return  signal 
as  a function  of  the  apparent  aspect  angle  of  the  aircraft  as 
viewed  by  the  radar.  These  effects  are  illustrated  in  figure  3-4. 

The  Target  Generator  Module  simulates  the  overall  effect  by  permitting 
the  assignment  of  a value  of  radar  cross-section  (RCS)  to  each  of 
eight  views  of  the  aircraft  (this  sets  the  mean  value  for  each 
octant),  and  to  this  mean  value  two  scintillation  values  are  added. 
Both  scintillation  values  are  defined  by  some  form  of  quasi-random 
process;  one  value  is  varied  on  a scan-to-scan  basis,  the  other  on  a 
pulse-to-pulse  basis.  Figure  3-5  illustrates  the  technique. 
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Figure  3-4.  Typical  Aircraft  Response  as  a Function 
of  Aspect  Angle 


• 5 MEAN  VALUES  OF 
RCS  ARE  USED 

• SCINTILLATION  ADDED 
TO  THESE  MEAN  VALUES 

• SCAN -SCAN  SCINTILLATION 
24  OB  PEAK -PEAK 

• PULSE-PULSE  SCINTILLATION 
12  DB  PEAK- PEAK 

• SCINTILLATION  DERIVED 
FROM  RANDOM  NUMBERS 
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Figure  3-5.  Technique  Used  to  Simulate  Aircraft 
Response 
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SECTION  IV 
RESULTS 


The  photographs  shown  in  this  section  illustrate  the  quality  of 
the  synthesized  responses  generated  by  the  simulator.  To  those 
familiar  with  radar  PPI  displays  the  images  appear  a little  empty 
since  the  simulation  does  not  yet  include  the  effects  of  clutter 
and  weather.  However,  the  character  of  the  display  responses  to 
individual  aircraft,  the  movement  and  scintillation  associated 
with  them,  and  the  quite  normal  limited  dynamic  range  shown  in 
the  display  signal,  all  contribute  to  a very  satisfactory  acceptance 
by  experienced  observers.  Two  display  samples  are  given  in  the 
following  pages  and  they  show  results  typical  of  the  radar  simulator. 
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Fill u re  4-1.  PP 1 Display.  Sample  1 

This  photo  shows  the  CPI  display  produced  on  an 
AN ^ UP A- 35 . The  radar  center  is  offset  to  emphasise 
the  effect  of  range.  This  photo  was  made  with  a 
time  lapse  egual  to  one  scan  of  the  radar. 
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Figure  4-2.  PPI  Display,  Sample  2 

This  photo  is  similar  to  figure  4-1,  except  that 
the  range  is  reduced,  and  in  addition  the  time 
lapse  covered  3 scans  of  the  radar;  this  disting- 
uishes the  targets  according  to  their  speed. 
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st n ion  v 


The  IR.tP  Project  4490  was  established  with  several  objectives: 

1)  to  demonstrate  our  initial  belief  that  distributed 
processing,  coupled  with  the  use  of  generous  "design 
space,"  offers  an  opportunity  to  reduce  system  cost, 
reduce  development  time,  and  provide  system  flexibility. 

.')  to  provide  some  experience  in  designing  a system 
utilizing  distributed  processing  techniques.  We 
were  interested  in: 

- architecture  and  its  impact  on  module  design 

- possible  problems  in  module-level  and  system-level 
test i nq 

- possible  problems  in  system  integration 

- the  deliberately  inefficient,  use  of  hardware, 
and  its  impact  on  the  module  design. 

3)  to  build  equipment  which  could  be  used  as  a base  for 
further  work  in  either  distributed  processing  or 
simulators.  To  this  end  the  equipment  was  required  to 
have  a design  which  would  gracefully  permit  expansion 
into  a full  system. 

Having  now  completed  the  work  planned  for  Project  9490  we  can  assess 
the  extent  to  which  we  have  met  these  objectives. 

We  have  found,  ax  we  expected,  that  when  a designer  is  given  plenty 
of  design  space  hardware  or  software  then  the  design  can 
proceed  in  an  orderly  wav  with  a minimum  of  deviation  from  an 
expeditious  schedule.  Distributed  processing  makes  the  concept 
practical  since  design  space  is  only  provided  in  the  modules  to  the 
extent  necessary  to  meet  the  individual  module  tasks.  In  contrast, 
providing  generous  "design  space"  for  a central ized-processing  approach 
requires  Provision  on  a total-svstem  basis,  which  then  becomes 
uneconomical  . 
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With  this  project,  the  software  design  in  the  supervisory  network, 
and  both  the  hardware  and  software  design  in  the  target  generator 
module,  proceeded  in  a very  straightforward  manner.  Once  the  system 
design  and  master-slave  bus  specifications  were  established,  the 
design  of  the  target  generator  module  was  implemented  with  no  sub- 
sequent changes,  nor  were  any  difficulties  in  execution  encountered. 
With  the  suDervisory  network,  there  were  a number  of  changes  made 
in  the  software  as  we  recognized  the  need  to  perform  more  functions; 
however,  the  generous  computation  time  and  available  memory,  coupled 
with  the  use  of  FORTRAN,  permitted  modifications  to  be  implemented 
quickly,  easily,  and  without  resort  to  clever  programming. 

The  project  experience  led  us  to  recognize  that  simply  employing 
distributed  processing  is  not  sufficient  to  assure  an  economical 
design  — one  could  otherwise  devise  a distributed-processing  system 
no  better  than  a central ized-processinq  system  with  its  attendant 
problems  in  programming  and  complexity.  What  is  important  is  that 
certain  princioles  obtain,  namely  that  the  segregated  tasks  are 
self-contained  as  far  as  possible,  and  that  communication  among  the 
modules  be  simple  in  nature  and  limited  in  rate.  We  also  recognized 
with  the  simulator  that  the  design  should  avoid  bi-lateral  communica- 
tion among  the  modules,  this  being  necessary  to  avoid  contention  for 
control  of  the  module  operation.  This  is  much  like  "structured 
programming"  which  insists  on  only  one  entrance  and  only  one  exit. 

With  regard  to  testing,  we  found  no  problem  at  either  the  module 
level  or  the  system  level.  For  example,  with  the  video  generator 
module,  testing  was  not  difficult  although  a fully  run  test  might 
have  been  more  time  consuming.  Inputs  to  the  module  consist  of 
simple  digital  words  of  standard  form,  and  the  output  is  a stream 
of  pulses  of  specified  amplitude  and  time  location;  all  of  these 
input/output  elements  are  easy  to  observe  and/or  measure.  We 
acknowledge  that  the  testing  was  facilitated  by  a development  aid 
designed  into  the  module,  and  the  simplicity  in  testing  resulted 
somewhat  from  the  simulator  being  a "small  system",  as  distinct  from 
some  of  the  more  complex  networks  found,  for  example,  in  systems. 

A basic  principle  remains  however  — testing  in  a distributed- 
processing  network  is  inherently  easier  than  in  a central ized- 
procqssing  network. 

System  integration  also  proceeded  in  a straightforward  manner; 
this  was  expected  because  the  module  tasks  were  well  defined  and 
segregated,  and  the  communication  between  the  modules  was  simple 
and  very  limited  in  nature.  When  system  design  incorporates  these 
features,  system  integration  is  facilitated  since  there  is  a higher 
certainty  that  the  system  components  will  integrate  compatibly. 
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Also,  once  the  system  is  fully  intearated,  fault  location  is  easier, 
since  the  operation  of  the  various  modules  can  he  more  easily 
observed  and  evaluated. 


Our  interest  in  the  "inefficient  use  of  hardware"  reflected  a 
conviction  that,  by  essentially  disregarding  the  quantity  of  hard- 
ware employed,  one  can  make  a reduction  in  development  cost  by 
reducing  development  labor.  "Inefficient  hardware"  provides  in  part 
the  "design  space'  referred  to  earlier.  (The  other  contributor  is 
the  proper  partitioning  of  the  system  problem).  It  was  not  necessary 
to  evaluate  alternate  module  designs  since  the  use  of  "inefficient 
hardware"  granted  a high  probability  of  success  to  the  first- 
proposed  and  not  critically  optimized  approach.  With  the  target 
generator  module  the  first-proposed  approach  was  in  fact  successful. 

The  initial  equipment  we  have  built  has  certainly  done  all  we  expected 
of  it,  and  in  fact  some  of  the  fine-grain  details  as  viewed  on  the 
PPI  display  are  very  pleasing.  The  equipment  is  verv  presentable  in 
appearance,  and  is  well  fitted  to  our  objectives  in  demonstrating 
the  system  capabilities. 

To  complete  the  summary  we  offer  a commentary  on  the  possible 
exploitations  of  this  initial  development.  Several  avenues  merit 
consideration:  further  development  on  simulators  of  various  types, 
further  exploration  into  the  design  of  distributed-processing 
networks,  and  the  application  of  this  approach  to  ECM/ECCM  issues 
of  interest  to  both  radar  and  communication. 

Further  development  on  simulators  might  be  directed  towards 
completion  of  the  existing  system,  or  it  could  easily  branch  out  to 
radars  which  use  B-scan  displays  — precision  approach  radars  and 
sector  surveillance  radars  — or  conical  scan  radars.  Also,  by 
utilizing  an  RF  signal-aeneration  version  of  the  concept,  one  could 
simulate  a variety  of  adversary  situations  and  evaluate  both  ECM 
and  ECCM  techniques. 

Since  the  system  utilizes  separate  modules  to  simulate  the  various 
elements  in  a complex  system,  the  concept  is  directly  applicable 
to  a communication  system  at  tempt i no  to  communicate  in  the  presence 
of  jamming.  Simulation  of  such  a network  would  be  useful  in  exploring 
the  benefits  of  anti -jam  techniques,  as  well  as  the  effectiveness 
of  different  jammers. 

In  sunmary.  Project  9490  was  established  with  several  objectives; 
the  work  is  now  complete,  and  the  objectives  satisfied;  opportunities 
to  further  exploit  the  work  are  also  readily  apparent. 
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ECM  Electronic  Countermeasures 
ECCM  Electronic  Counter  Countermeasures 
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